1. Technical Field
The present invention relates to computer filesystems and, in particular, to access control lists in computer filesystems. Still more particularly, the present invention provides a method, apparatus, and program for providing multiple simultaneous access control list formats on a filesystem.
2. Description of Related Art
Access control lists have become a common security feature in filesystems. An access control list (ACL) allows control of access to a file system object to be specified to the granularity of individual users or groups.
Early file system control mechanisms, such as those provided by the USG and BSD UNIX file systems, allowed access rights to be specified in terms of the object owner, the group associated with the object owner, and all other users who were neither the object owner nor members of the object owner's group. Each of those three entries provided a set of three permissions, read, write, and execute, with the interpretation of those permissions differing between file system objects which were directory objects and those which were not.
Extensions to that model, such as the ACL model provided by the UNIX System V Release 4 (SVR4) filesystem, allow additional user and group entries to be defined with each entry granting access to the same set of three permissions as the three base (object owner, object group, other) entries. A user or group entry is referred to as an access control entry (ACE). SVR4 enforces a rule requiring that all user-based ACEs be defined before all group-based ACEs, with the other permissions defined last.
The SVR4 ACL is evaluated in the order given, with the first matching user or group entry specifying the permissions which were granted. If no entries match the user or group values associated with the requesting process, the other permissions are used. This is an example of an “ordered” ACL.
Other ACL models, such as the ACL model provided by the AIX Version 3.1 (AIX) file system, allow additional entries to be defined with the identity portion of the entry allowing for inclusion of user and group identity information within a single entry. Access to the same set of read, write, and execute permissions can be specified in terms of granting access (permit), denying access (deny) or both granting the given permissions and denying the permissions which were not granted (specify).
No ordering rules, other than that the object owner and object group permissions are considered first, are imposed upon AIX ACLs. The AIX ACL is evaluated from beginning to end, with each matching entry used to determine the final set of access permissions. If no entries match the user or group values associated with the requesting process, the other permissions are used. This is an example of an “unordered” ACL.
The filesystem and/or ACL model may be chosen based upon preference or need. However, in a network data processing system, several disparate filesystems and ACL models may exist. The task of converting from one ACL type to another becomes critical in a network environment with heterogeneous filesystems and ACL models. However, as filesystems increase in complexity, this task becomes more difficult.
One solution to this problem is for every filesystem to use the same ACL model. The most recent attempt at creating a standard ACL interface was undertaken by the Portable Operating System Interface for UNIX (POSIX) security working group. This standard ACL model was originally known as POSIX standard 1003.6, which is now 103.1e but commonly referred to as “dot6.” When working group members were unable to reach a consensus on ACLs and many other security features, the standard was abandoned.
Interest in the POSIX ACL model has increased with the open source community with dot6 implementations on such systems as Linux and FreeBSD. Despite the attempt at creating a de facto ACL standard by embracing the defunct dot6 standard, vendors have proceeded to create ACL models which are supersets of dot6 or completely unrelated to dot6. Thus, it would appear that there may never be a standard ACL model.
Another solution in a heterogeneous network environment is to perform individual filesystem-to-filesystem conversions on ACLs. Each filesystem must be modified to perform a conversion for every other ACL model on the network. This solution is cumbersome and possibly inaccurate.
Therefore, it would be advantageous to provide an improved mechanism for administering and maintaining access control lists for multiple, differing filesystem types.